It is known to store data on a device in a manner that “locks” the stored data to the device, i.e. so that the stored data, if transferred to a second device, cannot be used on that second device. The data may, for example, comprise a cryptographic key for use by an application on the device to access (e.g. decrypt, or enable decryption of) content being stored on the device as encrypted content—in this way, even if the data and the encrypted content are distributed to other devices in an unauthorized manner, those other devices will not be able to access the content as those other devices will not be able to successfully (or correctly) use the data.
FIG. 1a of the accompanying drawings is a flowchart schematically illustrating a method 100 of storing and accessing an amount of data D in a manner that locks the amount of data D to a device. The device may be any kind of data processing device, such as a desktop computer, a mobile telephone, a laptop, a tablet computer, a set top box, a smart card, a games console, etc. The method 100 may be implemented in dedicated hardware, as software executing on a processor of the device, or as a combination of hardware and software.
At a step 102, the amount of data D is stored on the device for the first time, i.e. the device is initialized with the amount of data D. The amount of data D is not stored in clear form, but is stored in a protected form so that the amount of data D may not be determined directly by inspecting the contents of a memory or storage medium of the device. This step is sometimes referred to as an “enrolment” step.
For example, when initially installing an application (e.g. a computer program or other software) on a device, the installation process may create the amount of data D for subsequent use by the application and store that amount of data D at the step 102.
As mentioned, the amount of data D is stored in protected form. If this protected form is copied to another device, the intention is that that other device will not be able to determine, or access, the amount of data D from the copied protected form of the amount of data D.
An example of the processing performed at the step 102 shall be described shortly with reference to FIG. 1b of the accompanying drawings.
At a step 104, the device (or an application executing or running on the device) attempts to access the amount of data D using the protected form of the amount of data D. If the device that carries out the step 104 is the device to which the protected form of the amount of data D corresponds (i.e. it is the device to which the stored amount of data D is locked at the step 102), then at the step 104 the device should be able to access the amount of data D. If, on the other hand, the device that carries out the step 104 is not the device to which the protected form of the amount of data D corresponds (i.e. it is not the device to which the stored amount of data D is locked at the step 102), then at the step 104 the device should not be able to access the amount of data D.
An example of the processing performed at the step 104 shall be described shortly with reference to FIG. 1c of the accompanying drawings.
FIG. 1b is a flowchart schematically illustrating a method 130 for storing the amount of data D on a device, in a manner that locks the amount of data D to that device. The method 130 may be carried out, for example, to implement the step 102 of FIG. 1a, although it will be appreciated that other methods for implementing the step 102 of FIG. 1a could be used instead.
At a step 132, a characteristic C of the device is obtained (or determined or measured). The characteristic C is a value (or an identifier or code) that identifies the device, or that distinguishes the device from other devices. There are many known ways of obtaining a characteristic C of the device. For example, the characteristic C may be based on one or more of:                A serial number of a storage medium (e.g. a magnetic disc, a memory chip, etc) of the device.        A serial number of a processor of the device.        A serial number of any other component of the device or of the device itself.        Contents of memory during start-up of the device.        One or more properties of a component of the device, such as a processing speed of a processor of the device, a storage capacity of a storage medium of the device, a number of USB ports of the device, a resolution of a screen of the device, etc.        An identifier of one or more software applications installed on the device, or of one or more modules, elements, plug-ins, etc. of the one or more applications—for example, the version of a browser installed on the device and identities of modules (e.g. language packs, toolbars, etc.) that are installed for that browser.        Any other information, aspect, property, feature or configuration of the device.Such data about the device and its current configuration may be collected. As this data may be of variable size (depending on the nature of the device and how it is currently configured), a hash of the collected data may be generated, so as to obtain a predetermined fixed-length value from the collected data. The characteristic C may be set to be this hash value. However, it will be appreciated (and is known to the skilled person) that the characteristic C may be formed from the collected data in any other suitable way.        
Error correction codes (ECCs) are well-known—examples of ECCs include Reed-Solomon codes, BCH codes, Turbo codes, etc. In particular, given an amount of data X, an ECC may be used to generate error correction data Y for the data X (or redundancy data, sometimes referred to as a checksum or a parity check). The ECC encoded version, or codeword, W for the data X may then be set to be W=X∥Y (where herein, a∥b represents the concatenation of data a with data b)—this form of ECC encoding is known as systematic ECC encoding. ECCs use a corresponding symbol alphabet (which is often a Galois field of size 2s for some positive integer s)—the original data X, the error correction data Y and thus the codeword W are represented using symbols of that alphabet. The error correction data Y is based on the original data X and is arranged such that if one or more errors are introduced into the codeword W, so as to generate a modified value W* (i.e. a new version W* of the codeword W where one or more of the symbols representing W* differ from the symbols at corresponding locations in the codeword W), then those errors can be corrected so as to obtain the original codeword W from the value W*. The number of errors that can be introduced into the codeword W to generate the value W* whilst still being able to regenerate the original codeword W from the value W* is called the error-correction-capability, α, of the ECC—this is a predetermined number for the ECC which may be set by setting appropriate parameters for the ECC. The errors may be corrected whether they are introduced into the data X within the codeword W=X∥Y and/or into the error correction data Y within the codeword W=X∥Y. However, in situations in which it is known that the errors will only occur in the original data X, then the error correction data Y may be viewed as data that enables correction of up to a predetermined number (the error-correction-capability, α, of the ECC) of errors in a version X* of the data X (where W*=X*∥Y).
As ECCs are well-known, further detail regarding ECCs, ECC encoding, ECC decoding, or other operations involving ECCs shall not be described herein.
At a step 134, error correction data R for the characteristic C is generated using an ECC. As discussed above, the error correction data R is data that enables correction of up to a predetermined number (the error-correction-capability α of the ECC) of errors in a version of the characteristic C—i.e. if a version C* of the characteristic C is generated, where the version C* has a number N (where 0≤N≤α) of errors or differences relative to the characteristic C, then the characteristic C may be regenerated or obtained from the version C*.
As mentioned above, ECCs are very well-known. The ECC used at the step 134 may be selected from any known (or future) ECCs that provide error correction data Y for an amount of input data X (as set out above).
At a step 136, storage data P is generated by combining the characteristic C with the amount of data D. In FIG. 1b, this is shown as creating the storage data P by XORing the characteristic C with the amount of data D—i.e. P=C⊕D. In this example, it is being assumed that the data D and the characteristic C are of the same length (or size)—if the initial values for the characteristic C and the amount of data D are not the same length, then they can be made to be the same length by, for example: (i) if the characteristic C is longer than the amount of data D, truncating the characteristic C so that it is the same length as the amount of data D, or expanding the amount of data D by repeating bits of the amount of data D so that the expanded amount of data D is the same length as the characteristic C; or (ii) if the characteristic C is shorter than the amount of data D, expanding the characteristic C by padding the characteristic C with padding bits (which could, for example, be existing bits of the characteristic C, or bits generated by forming one or more hashes of the characteristic C, etc.).
It will be appreciated, however, that the storage data P may be formed from the characteristic C and the amount of data D using any other method. All that is required is that the amount of data D can be obtained from the storage data P if the value of the characteristic C is known. In particular, the storage data P may be formed as a function F of the amount of data D and the characteristic C, i.e. P=F(D,C), where the function F has a corresponding function G such that G(P,C)=G(F(D,C))=D. The function F may be viewed as an invertible function (where G=F−1, i.e. the inverse of F) that is keyed, or seeded, by the characteristic C. The XOR given in the example above is, of course, just one example of such a function, and it will be appreciated that any other such function could be used instead. Preferably, though, the amount of data D is not obtainable from the storage data P without (knowledge of) the characteristic C.
At a step 138, a digital signature Sig of a quantity of data comprising (or that is a function of) the storage data P and the error correction data R is generated, for example, a digital signature Sig of just the pair {R,P}. For this, a signature key SK is used.
The signature Sig may be generated by using an asymmetric digital signature algorithm. In this case, the signature key SK is a private key that corresponds to a public verification key VK. The device may store the verification key VK for future use (as explained shortly with reference to FIG. 1c). The signature key SK may be a private key associated with the device—the device may store the signature key SK, or, alternatively, the signature key SK and the verification key VK may be generated by the device during the step 102, with the verification key VK being stored for subsequent use and the signature key SK being discarded after the step 138. In some embodiments, the step 138 is performed by the device, with the device knowing the signature key SK. In other embodiments, the device does not have access to the signature key SK and only has access to the corresponding verification key VK (e.g. the verification key is hardcoded into the device)—for example, the signature key SK may be a signature key used by, or associated with, a manufacturer of the device, in which case the manufacturer may generate the signature Sig when the manufacturer initially makes and initialises the device with the amount of data D.
Alternatively, the signature Sig may be generated by using a symmetric digital signature algorithm (e.g. the signature Sig may be a message authentication code). In this case, the signature key SK is a secret key of the device that is stored by the device—the signature key SK may be used as a verification key VK (i.e. VK=SK) in the future (as explained shortly with reference to FIG. 1c).
Digital signatures schemes/algorithms (both symmetric and asymmetric) are well-known and shall, therefore, not be described in more detail herein.
At a step 140, the device stores: the error correction data R, the storage data P and the generated signature Sig. This stored data represents the amount of data D and is the above-mentioned protected form of the amount of data D.
FIG. 1c is a flowchart schematically illustrating a method 150 for controlling access to the amount of data D at (or stored on) a device. The device is storing a protected form of the amount of data D, where this protected form of the amount of data D was generated using the method 130 of FIG. 1b. The method 150 may be carried out, for example, to implement the step 104 of FIG. 1a, although it will be appreciated that other methods for implementing the step 104 of FIG. 1a could be used instead.
At a step 152, the protected form of the data is retrieved (e.g. from the memory or storage of the device at which the protected form of the data is located). Thus, at the step 152, the error correction data R, the storage data P and the generated signature Sig are obtained or accessed.
At a step 154, the signature Sig is verified against (or for or in relation to) a quantity of data comprising the storage data P and the error correction data R. This quantity of data is formed in the same way in which the quantity of data that was signed at the step 138 of FIG. 1b to generate the signature Sig was formed—for example, the quantity of data may be just the pair {R,P}. The verification of the signature Sig uses a verification algorithm corresponding to the signature generation algorithm, and makes use of the verification key VK corresponding to the signature key SK that was used to generate the signature Sig. Such verification algorithms are well-known and shall not be described in detail herein.
If, at a step 156, it is determined that the verification at the step 154 has failed (i.e. the signature Sig does not correspond to the quantity of data comprising the storage data P and the error correction data R), then processing terminates at a step 158. If, on the other hand, it is determined at the step 156 that the verification at the step 154 has succeeded (i.e. the signature Sig corresponds to the quantity of data comprising the storage data P and the error correction data R), then processing continues at a step 160.
At the step 160, a current characteristic C* of the device is obtained (or determined or measured). This is performed in the same way in which the characteristic C of the device was obtained at the step 132 of FIG. 1b. There are four possible scenarios:                (S-a) The device carrying out the step 104 is the same as the device that carried out the step 102, and the configuration/state/etc. of the device has not changed since the protected form of the amount of data D was generated and stored: in this case, the current characteristic C* will be the same as the original characteristic C (obtained at the step 132 of FIG. 1b).        (S-b) The device carrying out the step 104 is the same as the device that carried out the step 102, and the configuration/state/etc. of the device has changed slightly (or by a sufficiently small amount) since the protected form of the amount of data D was generated and stored: in this case, the current characteristic C* may differ from the original characteristic C (obtained at the step 132 of FIG. 1b) by at most a symbols or places, where a is the error-correction-capability of the ECC that was used at the step 134 of FIG. 1b—this means that these errors can be corrected using the error correction data R, and that the original characteristic C may be obtained (or restored) from the current characteristic C*.        (S-c) The device carrying out the step 104 is the same as the device that carried out the step 102, and the configuration/state/etc. of the device has changed significantly (or by a sufficiently large amount) since the protected form of the amount of data D was generated and stored: in this case, the current characteristic C* may differ from the original characteristic C (obtained at the step 132 of FIG. 1b) by more than a symbols or places, where a is the error-correction-capability of the ECC that was used at the step 134 of FIG. 1b—this means that these errors cannot all be corrected using the error correction data R, so that the original characteristic C cannot then be obtained (or restored) from the current characteristic C*.        (S-d) The device carrying out the step 104 is different from the device that carried out the step 102 (i.e. the protected form of the amount of data D has been transferred or copied to a different device): in this case, the current characteristic C* will almost certainly differ from the original characteristic C (obtained at the step 132 of FIG. 1b) by more than a symbols or places, where a is the error-correction-capability of the ECC that was used at the step 134 of FIG. 1b—this means that these errors cannot all be corrected using the error correction data R, so that the original characteristic C cannot then be obtained (or restored) from the current characteristic C*.        
At a step 162, an error-correction decoding operation is performed on the current characteristic C* using the error correction data R to (try to) correct any errors that may exist in the current characteristic C* relative to the original characteristic C. The result of this error-correction decoding operation is a value C′. As discussed above, in scenarios (S-a) and (S-b) above, the original characteristic C is obtained from this error-correction decoding operation (i.e. C′=C); whereas in scenarios (S-c) and (S-d) above, the original characteristic C will almost certainly not be obtained from this error-correction decoding operation (i.e. C′≠C).
At a step 164, an amount of data D′ is obtained or generated from the characteristic C′ and the storage data P. In particular D′=G(P,C′)—i.e. the step 164 obtains the amount of data D′ from the characteristic C′ and the storage data P using the inverse of the method (or function F) by which the storage data P was generated from the amount of data D and the characteristic C. In scenarios (S-a) and (S-b) above, C′=C, in which case D′=D, i.e. the step 164 generates the original amount of data D; whereas in scenarios (S-c) and (S-d) above, C′≠C, in which case D′≠D, i.e. the step 164 generates an amount of data D′ different from the original amount of data D.
At a step 166, the generated amount of data D′ is output or provided. Thus, if the step 104 of FIG. 1a is being performed on the same device as the device that performed the step 104 of FIG. 1a, and if the configuration of this device has not changed significantly, then the device can access the originally stored amount of data D; otherwise, the amount of data D will not be accessed at the step 104 of FIG. 1a. 
In this way, the amount of data D may be stored on the device in a manner that “locks” the stored amount of data D to the device.
The problem scenario is, of course, scenario (S-c) set out above—in this scenario, the device that is trying to access the amount of data D is the correct physical device (i.e. the same device that originally stored the amount of data D in a protected form and to which the stored amount of data D is locked), however this device has been changed (e.g. by the addition, removal, or replacement of hardware, applications, software components, plug-ins, etc.) to such an extent that the current characteristic C* of this device is too different from the original characteristic C of this device, i.e. the number of differences between C and C* exceeds the error-correction-capability α of the ECC. Thus, a user of the device may: start in scenario (S-a) and thereby have access to the amount of data D; move to scenario (S-b) at some later point, e.g. due to some minor changes that the user makes to the device and still have access to the amount of data D; and then move to scenario (S-c) at some later point, again due to some further minor changes that the user makes to the device, at which point the device will not be able to access the amount of data D. This will occur despite the fact that the change to the device that moves the device from being in scenario (S-b) to being in scenario (S-c) may be very minor—as far as the user of the device is concerned, he has just made a very minor modification to his device (which may be completely unrelated to the use or purpose of the amount of data D), and now he is no longer able to carry out the functionality that would make use of the amount of data D (e.g. decrypting encrypted content).